E,Low coupling,Low maintainability,Manual testing,Decision of speed rather than quality,Clear division of responsibilities,Internal validation of work,Version control,Google Docs,Digital kanban for requirements documentation,Whiteboard task management,Informal project management,Agile development,Software design for independent work,New fitting framework,Lean Development,Self-imposed deadline,Design & practices support independent work methods,Software architect role,44,37,18,Less disciplined version of Agile development effective due to small team size,Minimal use of Kanban boards due to small team size <= 5,Software structure supported low coupling of components,Lesson learnt: Project might have benefitted from more research into the needs intending to be fulfilled.,Team set themselves a clear time limit for prototype development,Division of project responsibilities between team members,Demand for solution had already been verified,No documentation of software design decisions,End users viewpoint basis for decision making,No automated testing,Frequent meetings to discuss frequently changing requirements,Informal verbal division of tasks,Modular software architecture to enable independent work,Non-developer founder as end user stand-in,No formal testing due to time constraints,Low maintainability deemed acceptable for a rapid rush to first release – cost of increasing quality too high in this context,Loosely Agile development,Data architecture of product is not scalable,No generation of software documents,Goals/Requirements stated in Trello,Coding standards to homogenize code from different developers,Accelerator participation too time consuming – reduced time available for software development,Product source was managed in version control,Infrequent external user test-drive for feedback,Impromptu 10 minute meetings for big decisions,Software component structure visible in file system hierarchy,Impromptu verbal decision making,In house task verification and validation,No defined quality management process,Continuous integration,No organized unit testing,Non-developer founder had full trust in development part of founding team,Whiteboard effective for rapidly changing information,Developers‘ ability to follow own work strategies supported success,One team member responsible for software architecture,Team member responsible for architecture chose exciting new framework that was expected to fit the project.,Designated third person to resolve management disagreements,Informal testing of own code,A testing schema and code architecture design would incur too great of an overhead for project/team size of <=5.,Lack of formal testing deemed effective for prototype development due to time savings,Google Docs for note keeping – accessible from anywhere,Internal demonstration of work for validation,Development team an effective balance of go-getting and cautious members,Prototype is final product
